The following abbreviations and terms are herewith defined, at least some of which are referred to within the following description of the state of the art and the present invention.
3GPP Third Generation Partnership Project
BTS Base Transceiver Station
DDC Device Detection Component
GMLC Gateway Mobile Location Center
GPS Global Positioning Satellite
GTCS Geo-Fencing Tracking and Control System
GUI Graphical User Interface
HLR Home Location Register
HSS Home Subscriber Server
IMSI International Mobile Subscriber Identity
LTE Long-Term Evolution
M2M Machine to Machine
MNO Mobile Network Operator
MPS Mobile Positioning Server
MSISDN Mobile Subscriber ISDN Number
MVNO Mobile Virtual Network Operator
OMA Open Mobile Alliance
OMA-DM Open Mobile Alliance-Device Management
RDM Remote Device Manager
ROM Read-Only-Memory
SGSN Serving GPRS Support Node
SNMP Simple Network Management Protocol
SMS Short Message Service
SUPL Secure User Plane Location
TCO Total Cost of Ownership
TR Technical Report
USSD Unstructured Supplementary Service Data
Firmware: Firmware is a software program or set of instructions programmed on a Device Processor (e.g., on an M2M device). The firmware provides the necessary instructions for how the device functions and communicates with the other hardware and software. Firmware is typically stored in the flash read-only-memory (ROM) of the hardware device. The ROM can be “flash” ROM which can be erased and rewritten only by an authorized user. Hence, firmware can be “semi-permanent” since it remains the same unless it is updated by a firmware updater. The firmware may be updated to provide the hardware device new functionality or to simply make the hardware device operate more efficiently.M2M: In the field of cell phone networks, M2M refers to devices other than cell phones which use the wireless network to communicate with other devices or networks. Typically, a small device known as an M2M module is embedded in a larger device that needs to communicate over the wireless network. The M2M module contains the same type of radio and data circuits that would be found in a typical cell phone, but nothing else (no display or keypad, etc.). M2M modules can be embedded in things such as vending machines, automobiles, containers, alarm systems, and remote sensors.
M2M communications over 3GPP networks and/or other access networks such as WiFi, Zigbee etc. . . . is a fast-expanding area. There are many drivers for this including the reduction in prices of the M2M devices in response to economies of scale and Moore's Law. M2M device management presents an interesting management challenge. In the past, “network management” addressed the management of network nodes, for instance core network elements like the SGSN, and radio network elements such as the BTS, routers etc. However, with the advent of M2M technology, the M2M devices themselves are part of what needs to be managed. This is conceptually similar to a mobile operator needing to manage all of the mobile handsets in their network via an operation center. There are applications available today for doing this, such as Ericsson's RDM (Remote Device Manager) platform which supports the remote management of TR069 enabled M2M devices. In this regard, the idea of “network management on a device level” is only the first part associated with the management of M2M devices. Next, we discuss the management of M2M devices in an even broader context.
Currently, most M2M solutions fit comfortably within one operator's network. In general, many of the M2M devices are not very mobile and the ones that are mobile are mobile within one network. Consider an application such as nascent M2M applications in automobiles that are even now migrating to 3GPP-based technology. It can be seen that in the vast majority of cases, sufficient connectivity can be provided under the umbrella of one operator, whether MNO or MVNO. However, with the advent of cloud computing there is a class of M2M applications that is now being deployed and that will expand very rapidly in the coming few years. This class of M2M applications is best exemplified by asset tracking and management. To exemplify this case, one can consider that of refrigerated container management. Refrigerated containers can contain perishable goods with a very high value. The refrigerated containers themselves need to be tracked, which is fairly simple, but more importantly, the conditions inside the refrigerated container need to be monitored and controlled. This level of management needs to be possible, in general, virtually anywhere in the world.
It can be readily appreciated that the M2M devices associated with these refrigerated containers (or other tracked components) will need to be managed well beyond the perimeters of a single operator's network. It can also be appreciated that this is true for an entire class of M2M devices which can be expected to be used globally. Finally, it should be noted that a large part of the world's surface is covered with water and that many of these M2M devices will spend a significant amount of time at sea, where connectivity can be provided via satellite-connected base stations, but where the connectivity costs are much higher due to the use of a satellite link. This operational context is the second part associated with managing M2M devices.
If one takes both parts of these operational contexts into account to manage M2M devices, it can be seen that there is a need for M2M device management on a pan-operator basis. From a pure communication point of view, this is not really an issue, as the M2M devices are either in a “home” operator network or in a “visited” network which is owned by the operator's roaming partner. In such cases, the M2M devices could be under coverage, either within their home network or a visited network, provided via a satellite link. However, there is one special case regarding network management on a M2M device level that should be addressed because it can significantly affect whether the specific M2M application can be profitably employed over the solution's lifespan. This one special case relates to firmware updates (i.e., software updates). Like many devices, M2M devices can, and will, require firmware updates. In some cases, these firmware updates are relatively minor, for instance to support minor enhancements. In other cases, these firmware updates are critical because the M2M devices may have been found to have performance faults which can result in the disruption to networks or the M2M device going “down” in a way that requires a great deal of manual intervention (e.g. tracking the container manually, resetting the communication device etc.) to address the particular problem.
As can be appreciated, to provide firmware updates for large numbers of M2M devices located in roaming “visited” partner networks or satellite-connected radio networks can be very expensive and can significantly affect the business case of the M2M application. In addition, there can be cost differentials associated with providing for firmware updates depending on whether a M2M device is active in a 2G, 3G or LTE network (consider data download speeds/volumes). Accordingly, there is a need for an effective way to manage firmware updates in a cohesive manner for a large number of M2M devices that can be basically located anywhere in the world, in the most cost-effective manner possible.